Method for visualizing results of root cause analysis on transaction performance data

ABSTRACT

Mechanisms for graph manipulation of transactional performance data are provided in order to identify and emphasize root causes of electronic business system transaction processing performance problems. A system transaction monitoring system, such as IBM Tivoli Monitoring for Transaction Performance™ (ITMTP) system, is utilized to obtain transaction performance data for a system. This transaction performance data is stored in a database and is utilized to present a graph of a given transaction or transactions. Having generated a graph of the transaction, and having identified problem conditions in the processing of the transaction(s), the present invention provides mechanisms for performing graph manipulation operations to best depict the root cause of the problems.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention is generally directed to a method and apparatusfor visualizing results of root cause analysis on transactionperformance data. More specifically, the present invention provides aplurality of graph manipulation mechanisms for providing alternativeviews of a transactional system architecture in order to emphasize andidentify root causes of detected problems.

2. Description of Related Art

IBM Tivoli Monitoring for Transaction Performance™ (hereafter ITMTP) isa centrally managed suite of software components that monitor theavailability and performance of Web-based services and operating systemapplications. ITMTP captures detailed transaction and applicationperformance data for all electronic business transactions. With ITMTP,every step of a customer transaction as it passes through an array ofhosts, systems, application, Web and proxy servers, Web applicationservers, middleware, database management software, and legacyback-office software, may be monitored and performance characteristicdata compiled and stored in a data repository for historical analysisand long-term planning. One way in which this data may be compiled inorder to test the performance of a system is to simulate customertransactions and collect “what-if” performance data to help assess thehealth of electronic business components and configurations. ITMTPprovides prompt and automated notification of performance problems whenthey are detected.

With ITMTP, an electronic business owner may effectively measure howusers experience the electronic business under different conditions andat different times. Most importantly, the electronic business owner mayisolate the source of performance and availability problems as theyoccur so that these problems can be corrected before they produceexpensive outages and lost revenue.

ITMTP permits, for a particular transaction, a user to generate a graph(topology) of the transaction. The graph is a tree that visuallydescribes a transaction through the enterprise software being monitored.While this graph provides an indication of the manner by which atransaction is processed by the various elements of the electronicbusiness, the graph does not provide a mechanism for isolating anddetecting the root causes of problems. That is, while ITMTP permitsusers to be alerted when there are problems, and a graph of thetransaction may be provided, there is no mechanism in ITMTP forisolating the root cause of the detected problem within the graph of thetransaction. Thus, it would be beneficial to have a mechanism forperforming graph manipulations for easily and quickly identifying andemphasizing root causes of problems in transaction processing of anelectronic business system.

SUMMARY OF THE INVENTION

The present invention provides a mechanism for graph manipulation oftransactional performance data in order to identify and emphasize rootcauses of electronic business system transaction performance problems.With the present invention, a system transaction monitoring system, suchas IBM Tivoli Monitoring for Transaction Performance (ITMTP) system, isutilized to obtain transaction performance data for a system, such as anelectronic business system. This transaction performance data may beutilized to determine when and where problem conditions occur.

This transaction performance data is stored in a database and isutilized to present a graph, or topology, of a given transaction ortransactions. The graph or topology represents the software componentsthat perform some processing of the transaction as it is handled by thesystem.

Having generated a graph of the transaction, and having identifiedproblem conditions in the processing of the transaction(s), the presentinvention provides mechanisms for performing graph manipulationoperations to best depict the root cause of the problems. Thedetermination of which graph manipulation mechanisms to utilize may beperformed automatically based on an analysis of the graph, may beperformed manually by a user making use of a graphical user interface,or a combination of automatic and manual selection of the graphmanipulation mechanisms.

The graph manipulation mechanism may include, for example, exclusion ofcertain nodes from the graph structure or inclusion of certain nodesfrom the graph structure in other nodes of the graph structure, based ona monitoring policy. Another mechanism may include a graph tree reversalmechanism for reversing or inverting a graph tree such that child nodesappear at the top of the graph tree. Child hiding is another usefulgraph manipulation mechanism of the present invention in which childnodes of graph nodes may be hidden to reduce the size of the depictedgraph tree. Another mechanism may be a unique parent view or commonchild view in which two unique parents who have a common child may beviewed as separate unique branches of a graph tree or may be viewed as agraph tree in which branches intersect.

Yet another graph manipulation mechanism of the present inventionincludes a host, transaction, application, user (HTAU) manipulation inwhich a user may expand a leaf node by virtual nodes corresponding tohosts, transactions, applications, or users. Other metrics or parametersassociated with the transaction could also be used in addition to, or inreplacement of, the host, transaction, application and user parametersto perform graph manipulations without departing from the spirit andscope of the present invention. In addition, other mechanisms forexpanding the leaf nodes may include selecting unique values of fieldsin tables associated with nodes so that only descendants that correspondto the selected field values are depicted.

In addition, the order of child nodes in the graph may be ordered basedon the identity of the child nodes. Also, the number of the child nodesmay be limited to a finite number in order to reduce the number ofdepicted child nodes such that the graph is more readable. Other graphmanipulation mechanism may be defined with the present invention inaddition to, or in replacement of, the above graph manipulationmechanisms without departing from the spirit and scope of the presentinvention.

These and other features and advantages of the present invention will bedescribed in, or will become apparent to those of ordinary skill in theart in view of, the following detailed description of the preferredembodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features believed characteristic of the invention are setforth in the appended claims. The invention itself, however, as well asa preferred mode of use, further objectives and advantages thereof, willbest be understood by reference to the following detailed description ofan illustrative embodiment when read in conjunction with theaccompanying drawings, wherein:

FIG. 1 is an exemplary diagram of a distributed data processing systemin which the present invention may be implemented;

FIG. 2 is an exemplary diagram of a client computing device which may beused to send transactions to elements of the present invention;

FIG. 3 is an exemplary diagram of a server computing device upon whichelements of the present invention may be implemented;

FIG. 4 is a conceptual diagram of an electronic business system inaccordance with the present invention;

FIG. 5 is an exemplary diagram illustrating the primary operationalelements of the present invention;

FIG. 6 is an exemplary diagram of a graphical display of a transactionin accordance with the IBM Tivoli Monitoring for TransactionPerformance™ tool;

FIG. 7 is an exemplary diagram illustrating a graph manipulationmechanism in which a monitoring policy eliminates nodes of a certaintype from the graphical representation in accordance with one exemplaryembodiment of the present invention;

FIG. 8 is an exemplary diagram of a tree reversal graph manipulationmechanism in accordance with one exemplary embodiment of the presentinvention;

FIG. 9 is an exemplary diagram of a child node hiding graph manipulationmechanism in accordance with one exemplary embodiment of the presentinvention;

FIG. 10 is an exemplary diagram of a unique parent view or common childview graph manipulation mechanism in accordance with one exemplaryembodiment of the present invention;

FIG. 11 is an exemplary diagram of a HTAU graph manipulation mechanismin accordance with one exemplary embodiment of the present invention;

FIG. 12 is an exemplary diagram of a parametric search graphmanipulation mechanism in accordance with one exemplary embodiment ofthe present invention;

FIG. 13 is an exemplary diagram of a child node ordering graphmanipulation mechanism in accordance with one exemplary embodiment ofthe present invention; and

FIG. 14 is a flowchart outlining an exemplary operation of the presentinvention when performing graph manipulations to identify and emphasizeroot causes of transactional processing problems in accordance with oneexemplary embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention provides a mechanism for graph manipulation oftransaction topology graphs so that root causes of problems in theprocessing of transactions are identified in the graph and emphasized.Since the present invention operates on transaction processing data fora system such as an electronic business system, the present invention isprimarily directed to use with systems that are intended to operate in adistributed data processing environment, such as the Internet.Therefore, the following figures, FIGS. 1-3, are provided as exampleenvironments in which aspects of the present invention may beimplemented.

With reference now to the figures, FIG. 1 depicts a pictorialrepresentation of a network of data processing systems in which thepresent invention may be implemented. Network data processing system 100is a network of computers in which the present invention may beimplemented. Network data processing system 100 contains a network 102,which is the medium used to provide communications links between variousdevices and computers connected together within network data processingsystem 100. Network 102 may include connections, such as wire, wirelesscommunication links, or fiber optic cables.

In the depicted example, server 104 is connected to network 102 alongwith storage unit 106. In addition, clients 108, 110, and 112 areconnected to network 102. These clients 108, 110, and 112 may be, forexample, personal computers or network computers. In the depictedexample, server 104 provides data, such as boot files, operating systemimages, and applications to clients 108-112. Clients 108, 110, and 112are clients to server 104. Network data processing system 100 mayinclude additional servers, clients, and other devices not shown. In thedepicted example, network data processing system 100 is the Internetwith network 102 representing a worldwide collection of networks andgateways that use the Transmission Control Protocol/Internet Protocol(TCP/IP) suite of protocols to communicate with one another. At theheart of the Internet is a backbone of high-speed data communicationlines between major nodes or host computers, consisting of thousands ofcommercial, government, educational and other computer systems thatroute data and messages. Of course, network data processing system 100also may be implemented as a number of different types of networks, suchas for example, an intranet, a local area network (LAN), or a wide areanetwork (WAN). FIG. 1 is intended as an example, and not as anarchitectural limitation for the present invention.

Referring to FIG. 2, a block diagram of a data processing system thatmay be implemented as a server, such as server 104 in FIG. 1, isdepicted in accordance with a preferred embodiment of the presentinvention. Data processing system 200 may be a symmetric multiprocessor(SMP) system including a plurality of processors 202 and 204 connectedto system bus 206. Alternatively, a single processor system may beemployed. Also connected to system bus 206 is memory controller/cache208, which provides an interface to local memory 209. I/O bus bridge 210is connected to system bus 206 and provides an interface to I/O bus 212.Memory controller/cache 208 and I/O bus bridge 210 may be integrated asdepicted.

Peripheral component interconnect (PCI) bus bridge 214 connected to I/Obus 212 provides an interface to PCI local bus 216. A number of modemsmay be connected to PCI local bus 216. Typical PCI bus implementationswill support four PCI expansion slots or add-in connectors.Communications links to clients 108-112 in FIG. 1 may be providedthrough modem 218 and network adapter 220 connected to PCI local bus 216through add-in connectors.

Additional PCI bus bridges 222 and 224 provide interfaces for additionalPCI local buses 226 and 228, from which additional modems or networkadapters may be supported. In this manner, data processing system 200allows connections to multiple network computers. A memory-mappedgraphics adapter 230 and hard disk 232 may also be connected to I/O bus212 as depicted, either directly or indirectly.

Those of ordinary skill in the art will appreciate that the hardwaredepicted in FIG. 2 may vary. For example, other peripheral devices, suchas optical disk drives and the like, also may be used in addition to orin place of the hardware depicted. The depicted example is not meant toimply architectural limitations with respect to the present invention.

The data processing system depicted in FIG. 2 may be, for example, anIBM eServer pSeries system, a product of International Business MachinesCorporation in Armonk, N.Y., running the Advanced Interactive Executive(AIX) operating system or LINUX operating system.

With reference now to FIG. 3, a block diagram illustrating a dataprocessing system is depicted in which the present invention may beimplemented. Data processing system 300 is an example of a clientcomputer. Data processing system 300 employs a peripheral componentinterconnect (PCI) local bus architecture. Although the depicted exampleemploys a PCI bus, other bus architectures such as Accelerated GraphicsPort (AGP) and Industry Standard Architecture (ISA) may be used.Processor 302 and main memory 304 are connected to PCI local bus 306through PCI bridge 308. PCI bridge 308 also may include an integratedmemory controller and cache memory for processor 302. Additionalconnections to PCI local bus 306 may be made through direct componentinterconnection or through add-in boards. In the depicted example, localarea network (LAN) adapter 310, SCSI host bus adapter 312, and expansionbus interface 314 are connected to PCI local bus 306 by direct componentconnection. In contrast, audio adapter 316, graphics adapter 318, andaudio/video adapter 319 are connected to PCI local bus 306 by add-inboards inserted into expansion slots. Expansion bus interface 314provides a connection for a keyboard and mouse adapter 320, modem 322,and additional memory 324. Small computer system interface (SCSI) hostbus adapter 312 provides a connection for hard disk drive 326, tapedrive 328, and CD-ROM drive 330. Typical PCI local bus implementationswill support three or four PCI expansion slots or add-in connectors.

An operating system runs on processor 302 and is used to coordinate andprovide control of various components within data processing system 300in FIG. 3. The operating system may be a commercially availableoperating system, such as Windows XP, which is available from MicrosoftCorporation. An object oriented programming system such as Java may runin conjunction with the operating system and provide calls to theoperating system from Java programs or applications executing on dataprocessing system 300. “Java” is a trademark of Sun Microsystems, Inc.Instructions for the operating system, the object-oriented programmingsystem, and applications or programs are located on storage devices,such as hard disk drive 326, and may be loaded into main memory 304 forexecution by processor 302.

Those of ordinary skill in the art will appreciate that the hardware inFIG. 3 may vary depending on the implementation. Other internal hardwareor peripheral devices, such as flash read-only memory (ROM), equivalentnonvolatile memory, or optical disk drives and the like, may be used inaddition to or in place of the hardware depicted in FIG. 3. Also, theprocesses of the present invention may be applied to a multiprocessordata processing system.

As another example, data processing system 300 may be a stand-alonesystem configured to be bootable without relying on some type of networkcommunication interfaces. As a further example, data processing system300 may be a personal digital assistant (PDA) device, which isconfigured with ROM and/or flash ROM in order to provide non-volatilememory for storing operating system files and/or user-generated data.

The depicted example in FIG. 3 and above-described examples are notmeant to imply architectural limitations. For example, data processingsystem 300 also may be a notebook computer or hand held computer inaddition to taking the form of a PDA. Data processing system 300 alsomay be a kiosk or a Web appliance.

One or more servers, such as server 104, may provide web services of anelectronic business for access by client devices, such as clients 108,110 and 112. With the present invention, a transaction performancemonitoring system is provided for monitoring performance of componentsof the web server and its enterprise back end systems in order toprovide data representative of the enterprise business' performance inhandling transactions. In one exemplary embodiment of the presentinvention, this transaction performance monitoring system is IBM TivoliMonitoring for Transaction Performance™ (ITMTP) which measures andcompiles transaction performance data including transaction processingtimes for various components within the enterprise system, errormessages generated, and the like.

From the compiled transaction performance data, a graph, or topology, ofthe transaction identifying the components of the enterprise system thatperformed some processing on the transaction is generated and acorresponding graph data structure is created. The graph may include aplurality of iconic depictions of nodes of the graph corresponding tothe type of component the node represents. In addition, performance datamay be superimposed or made available through this graph. For example,timing data for each component indicating how long each component tookto perform its processing on the transaction may be provided with eachiconic depiction of nodes in the graph. In addition, problem identifiersmay be provided with iconic depictions of nodes in which problems aredetected.

In the known systems, this graph or topology depiction is a fixedtopology with a graphical user interface that permits the user totraverse the graph and drill down from a collapsed system overview levelto an expanded system overview level, to a drill down view of thetransaction, and finally to a method call trace for a particularcomponent of the transaction. The present invention builds upon thisknown system and provides graph manipulation mechanisms for modifyingthe depiction of the graph or topology structure of the transaction suchthat the root cause of a problem in the processing of the transactionmay be clearly depicted in an emphasized manner in order to bring asystem administrator's attention to the root cause in order to aid inresolving problems in the enterprise system.

FIG. 4 is an exemplary diagram of an electronic business system inaccordance with a known transaction performance monitoring architecture.As shown in FIG. 4, a web server 410 is provided with which clientdevices 420-450 may communicate in order to obtain access to servicesprovided by the back-end enterprise computing system resources 460. AnITMTP system 470 is provided for monitoring the processing oftransactions by the web server 410 and enterprise computing systemresources 460.

The web server 410, enterprise computing system resources 460 and ITMTPsystem 470 are part of an enterprise system. Client devices 420-450 maysubmit requests to the enterprise system via the web server 410 whichcauses transactions to be created. The transactions are processed by theweb server 410 and enterprise computing system resources 460 with theITMTP system 470 monitoring the performance of the web server 410 andenterprise computing system resources 460 as they process thetransactions. This performance monitoring involves collecting andstoring data regarding performance parameters of the various componentsof the web server 410 and enterprise computing system resources 460. Forexample, monitoring of performance may involve collecting and storinginformation regarding the amount of time a particular component spendsprocessing the transaction, the bit rate of the component, an SQL query,component information including class name and instance id in the JAVAVirtual Machine (JVM), memory usage statistics, any properties of thestate of the JVM, properties of the components of the JVM, and/orproperties of the system in general.

The components of the web server 410 and enterprise computing systemresources 460 may include both hardware and software components. Forexample, the components may include host systems, JAVA Server Pages,servlets, entity beans, Enterprise Java Beans, data connections, and thelike. Each component may have its own set of performance characteristicswhich may be collected and stored by the ITMTP system 470 in order toobtain an indication as to how the enterprise system is handlingtransactions. More information regarding the manner by which the ITMTPsystem 470 collects performance data, stores it, and uses it to generatereports and transaction graph data structures may be obtained from theApplication Response Measurement (ARM) Specification, version 3.0, whichis available from the Open Group at www.opengroup.org/tech/management/arm/uploads/40/2459/ARM3Final.pdf, which is herebyincorporated by reference.

As mentioned above, the transaction data that is collected and stored bythe ITMTP system 470 is used to generate a graph data structure fordepicting the interaction of the components involved in processingtransactions. The graphical representation of the graph data structure,in a preferred embodiment, resembles a tree graph data structure inwhich nodes may be parent and/or child nodes in the tree graph datastructure. Parent nodes have pointers to their child nodes and childnodes have pointers to their parent nodes. A child node may be a parentto its own child nodes. In addition, each node has its own set ofcomponent attributes and may include method trace information foridentifying the methods executed by the component represented by thenode.

FIG. 5 is an exemplary diagram illustrating a graphical user interfacerepresentation of a transaction graph data structure. As shown in FIG. 5the graph data structure representation 500 includes a plurality ofnodes 510 representing various components of an enterprise system 520through which a transaction is processed. The nodes 510 representvarious components including the browser of the client device and theinternet host system (which are indicated as external to the enterprisesystem 520), JAVA Server Pages, servlets, entity beans, Enterprise JAVABeans, and data connections (which are also indicated as being externalto the enterprise system 520). Arrows between nodes 510 represent dataflow from component to component as the transaction is processed.

Various indicators may be provided associated with each iconicrepresentation of the enterprise system components. These indicators maybe used to identify the components where additional attention of thesystem administrator(s) is warranted. For example, these indicators mayidentify components where collected performance data indicates an error,less than acceptable performance, potential bottlenecks, and the like.

Nodes 510 in the graph data structure representation 500 are selectablein order to obtain more detailed information about the nodes 510. Forexample, a node may be selected in order to view the node's componentattributes, a method trace associated with the node, and the like.

FIG. 6 is an exemplary diagram illustrating a progression decomposing agraph data structure representation for a transaction from a systemoverview level to a method trace level. As shown in FIG. 6, a graph ortopology of a transaction may be provided, initially, in a collapsedsystem overview representation 610. The collapsed system overviewrepresentation 610 includes only a minimal number of nodes forrepresenting the enterprise system. This representation may be expandedto obtain an expanded system overview representation 620 in which thenodes in the collapsed system overview representation 610 are expandedso that their internal components at a next level of abstraction aremade visible.

The expanded system overview representation 620 may then be drilled downto a transaction representation 630 in which the components involved inthe transaction are represented in the depicted graph data structure.From there, individual nodes of the transaction representation 630 maybe selected to obtain a component attribute representation 640 and/or amethod call trace 650.

As discussed previously, the graph data structure representationsdescribed above, and illustrated in FIGS. 5 and 6 are fixed topologystructures. In other words, while a user may traverse the topology anddrill down into the topology, there are no mechanisms for modifying thetopology so that certain aspects of the topology are emphasized overother aspects of the topology. Of particular note is that there is nomechanism available in the known systems to modify the graph or topologyrepresentation such that root causes of problems in the enterprisesystem are brought to the forefront of the representation and areemphasized over other aspects of the topology. While for smaller, lesscomplicated enterprise systems, traversing this fixed topology may notcause much of an inconvenience to the human user, for more complexsystems, it may be quite daunting a task to identify the root cause ofan error or problem with the transaction processing.

The present invention builds upon the graph mechanism described above byproviding graph manipulation mechanisms for modifying the presentationof the transaction representation 630 such that the root cause ofproblems being experienced with the enterprise system are emphasized andare easily identifiable by users of the present invention, e.g., systemadministrators. The graph manipulation mechanisms of the presentinvention operate to modify an actual topology of the transaction, i.e.the topology through which the transaction is processed, into a modifiedtopology that is a change in the organization of component nodes whichmakes it easier for a human user to view the root cause of errors orproblems in the processing of the transaction. These graph manipulationmechanisms may be performed automatically by the graphical userinterface of a transaction processing performance monitor, may beselected by a human user of the graphical user interface, and/or acombination of automatic and user initiated graphical manipulationmechanisms may be utilized.

The actual topology or original transaction processing topology isrepresented as a first graph that is comprised of first nodes thatrepresent system entities involved in processing of a sub-transaction ofthe transaction, e.g., the systems and the network interconnections. Thefirst nodes may be child nodes, parent nodes, or both.

The present invention takes the actual topology represented by the firstgraph and generates a virtual topology, represented by a second graph,based on the actual topology. The second graph is a graph of nodes whichmay or may not correlate to nodes in the first graph. The second graphrepresents a higher level of abstraction, i.e. where the nodes areselective or a combination of nodes when compared to the first graph ofnodes. A second graph node may also be a child node, a parent node, orboth.

FIG. 7 is an exemplary diagram illustrating a graph manipulationmechanism in which a monitoring policy eliminates nodes of a certaintype from the graphical representation of the first graph to generate asecond graph, in accordance with one exemplary embodiment of the presentinvention. With this graph manipulation mechanism, a monitoring policymay be established that indicates the types of components that a systemadministrator, or other user, is not interested in seeing in thegraphical representation of the transaction topology. In other words,the monitoring policy may identify certain types of components for whichperformance monitoring is to be disabled. As a result, when thegraphical representation of the transaction topology is rendered, therendering engine compares the monitoring policy with attributes of thenodes that are part of the first graph or topology. If a node has anattribute identifying it as corresponding to a component that matchesthe component type or types in the monitoring policy, then the node willbe eliminated from the second graph of the transaction processingtopology.

The elimination of a node in the first graph when generating the secondgraph of the transaction processing topology involves identifying anyparent of the node to be eliminated in the first graph, and childrennodes of the node to be eliminated in the first graph, and thengenerating nodes in the second graph to graphically representing thechildren from the first graph as children of a parent node in the secondgraph corresponding to the parent node of the node that is to beeliminated in the first graph. This is illustrated in FIG. 7 in whichthe transaction processing topology or first graph includes a servletnode 710, an Enterprise Java Bean (EJB) node 720, and a Java DatabaseConnectivity (JDBC) node 730.

Assume that the monitoring policy established by the user states thatthe user is not interested in viewing nodes associated with EJBs. Thismay be the fact for many different reasons. For example, the user may beaware that there are a proportionally greater number of EJBs in theenterprise system than any other component and the user wishes tominimize the size of the graph so that possible error sources are moreeasily identifiable. Similarly, if the user has determined that, basedon historical information, root causes of errors typically do not arisein components of a certain type, these components may be eliminated fromthe transaction processing topology in order to simplify the topologyfor quicker identification of root causes of errors or problems withtransaction processing.

The essence of this graph manipulation is to use process of eliminationto find root cause. The user session during graph manipulationrepresents this process of elimination. Each successive graph representsa different model of the transaction. Each node represents a probableroot cause. By decreasing the number of nodes, the user is eliminatingpossible root causes. By increasing the number of nodes, the user isdetermining a more precise set of possibilities for a root cause.

When the monitoring policy is applied to the transaction processingtopology or first graph, the resulting second graph representationincludes only the servlet node 740, as a parent node, and the JDBC node750, as a child node of the parent node 740. With regard to the datastructure representing the first graph, the entries in the first graphdata structure are copied over to a second graph data structure and thenthe second graph data structure is used to generate the second graphrepresentation. During the copying over process, if an entry has anattribute identifying the component or node corresponding to the entryas being a component or node for which the monitoring policy indicatesmonitoring to be disabled, the entry is not copied over to the secondgraph data structure. Any parent entry and child entries of this entryare modified to point to each other. As a result, the parent entry ofthe removed entry is now the parent of the child entries of the removedentry, and the graphical representation is as shown in FIG. 7, elements740 and 750. This greatly simplifies the graphical depiction of thetransaction processing topology of the enterprise system when thetopology is complex.

The idea here is that two nodes may be different because of only theapplication associated to the node. By removing the applicationdistinction, the two nodes become the same, and so the view of the graphshows one node instead of two. This reduces the graph size, simplifyingthe view. In essence, the user is saying that the root cause is not theapplication, and to unbind it from the nodes.

It should be noted that the graphical user interface through which thegraphical depictions of the transaction processing topologies arepresented may include user selectable virtual buttons, menus, etc., viawhich the application of the monitoring policy may be removed from themodified graphical representation of the topology. In this way, thefirst graph representation of the transaction processing topology may beobtained from the second transaction processing topology.

FIG. 8 is an exemplary diagram of a tree reversal graph manipulationmechanism in accordance with one exemplary embodiment of the presentinvention. With this graph manipulation mechanism, a first graph may beinverted such that child nodes in the first graph are represented asparent nodes in the second graph. This type of graph manipulationmechanism is useful when it is determined that problems or errors in thetransaction processing typically occur with leaf nodes of thetransaction processing topology. As a result of this reversal, thesecond graph of the transaction processing topology has the most likelyroot cause of the error or problems at the top of the second graph.

In order to perform this reversal of the first graph to generate areversed second graph, a column of the first graph data structurerepresenting the child nodes and the column of the first graph datastructure representing the parent nodes are switched and stored in asecond graph data structure. As a result, the child nodes in the firstgraph are now parent nodes in the second graph and the parent nodes inthe first graph are now child nodes in the second graph. The graphicalrepresentation of the second graph is then generated using this secondgraph data structure.

An example of the graph reversal mechanism of the present invention isshown in FIG. 8. As shown in FIG. 8, an first graph 810 includes aparent node 812 that represents a servlet, a child node 814 of theparent node 812 which represents an Enterprise Java Bean, and a childnode 816 of the child node 814. When the first graph 810 is reversedusing the mechanisms of the present invention, the result is the secondgraph 820. The second graph 820 includes a parent node 822 thatcorresponds to child node 816, a child node 824 corresponding to childnode 814, and another child node 826 that corresponds to the parent node812.

Since, in many cases, the leaf nodes, or nodes nearest the leaf nodes,of the transaction processing topology tend to be the root cause ofprocessing problems or errors, by performing the reversal modificationof the present invention, the root cause node is brought to a moreprominent position in the second graph representation. While thedepicted examples are kept simple for clarification purposes, it can beappreciated that with complex topologies, such a reversal mechanism willgreatly speed up the locating of the root cause of problems beingexperienced with transaction processing.

FIG. 9 is an exemplary diagram of a child node hiding graph manipulationmechanism in accordance with one exemplary embodiment of the presentinvention. With this manipulation mechanism, child nodes of a parentnode in the first graph may be removed from the second graphrepresentation of the transaction processing topology. This permitssubtrees of the first graph to be removed from the graphicalrepresentation of the transaction processing topology.

From the standpoint of the first graph data structure, child nodes of adesignated parent node are not copied over to the second graph datastructure when generating the graphical representation of thetransaction processing topology. As a result, these child nodes are notincluded in the graphical representation that the user perceives.

An example of this child hiding mechanism is provided in FIG. 9. Asshown in FIG. 9, the first graph data structure includes a parent node910, a child node 920 of the parent node 910, and another child node 930of the child node 920. In the second graph, the child nodes 930 and 920are eliminated from the second graph and only a node 940 correspondingto the parent node 910 is present in the second graph. One way in whichthis child hiding may be performed is by eliminating the child nodecolumn of the first graph data structure in the second graph datastructure when the second graph data structure is generated.

FIG. 10 is an exemplary diagram of a unique parent view or common childview graph manipulation mechanism in accordance with one exemplaryembodiment of the present invention. This mechanism is used when thereare two parent nodes that have a common child node. This mechanismpermits the user to switch between a view of the transaction processingtopology in which common child nodes are repeated in separate treestructures corresponding to their parent nodes, and a view of thetransaction processing topology in which a single node is depicted forthe child node with all parent nodes of the common child node pointingto the single node. The separate tree representation is a defaultrepresentation in the first graph of the transaction processingtopology. The single node representation may be selected in order toreduce the number of redundant nodes present in the graphical depictionof the transaction processing topology.

FIG. 10 illustrates an example of the unique parent/common childrepresentations according to the present invention. As shown in FIG. 10,in a unique parent representation, the second graph structure includes aparent node 1010, a child node 1020 of the parent node 1010, and a childnode 1030 of the child node 1020. In addition, a separate tree isprovided having a parent node 1040, a child node 1050 of the parent node1040, and a copy of the child node 1030.

When switched to a common child representation, rather than having acopy of the common child node 1030 in each tree, the trees merge at thecommon child node 1030. That is, the child node 1020 and the child node1040 both point to the same single node representation of the commonchild node 1030. In this way, redundant nodes in the graphicalrepresentation of the transaction processing topology are removed andthus, the graphical representation is simplified making it lessdifficult to identify root causes of errors or problems in transactionprocessing.

FIG. 11 is an exemplary diagram of a Host, Transaction, Application,User (HTAU) graph manipulation mechanism in accordance with oneexemplary embodiment of the present invention. This graph manipulationmechanism permits the limitation of an first graph node's child nodesbased on one or more of the host, transaction, application, user, orother attributes of the actual node. That is, child nodes of a firstgraph node will only be included in the second graphical representationof the transaction processing topology if they include the same selectedattributes. For example, if a selected attribute is a particularapplication of the parent node, only child nodes that have the sameapplication attribute as the parent node will be included in the secondgraphical representation of the transaction processing topology.

In limiting the child nodes included in the second graphicalrepresentation, node entries from the first graph data structure arecopied to a second graph data structure. If a parent node has a selectedattribute, e.g., host, transaction, application, or user attribute, theneach child node entry in the first graph data structure is checked todetermine if they include the same selected attribute or attributes. Ifthe child node has the same selected attribute or attributes, it iscopied over to the second graph data structure. If it does not have thesame selected attribute or attributes, then the child nodes is notcopied over to the second graph data structure. If this child node isthe parent node of another child node, then a mechanism such as thatdescribed above with regard to FIG. 7 may be used to represent the childnodes. In this way, child nodes may be removed from the second graphicalrepresentation if they are not of interest to the user.

FIG. 11 illustrates an example of the HTAU graph manipulation mechanismof the present invention. As shown in FIG. 11, a first graph of thetransaction processing topology includes an EJB 1110 and a plurality ofchild nodes JDBC1 1120, JDBC2 1130, and JDBC3 1140. The EJB 1110 may beexpanded by selection of one or more attributes of the EJB with whichchildren are to be associated and displayed. Child nodes that do notcorrespond to the selected attributes are not displayed.

Thus, in the depicted example, since JDBC1 1120 and JDBC2 1130 haveattributes matching the selected attributes of the EJB 1110, i.e. hostnames that are host1.domain1.com or host2.domain1.com, these child nodesare displayed. Since JDBC3 1140 does not have a host name correspondingto either of hostl.domainl.com or host2.domain2.com, the JDBC3 node 1140is not displayed in the modified graph of the transaction processingtopology.

FIG. 12 is an exemplary diagram of a parametric search graphmanipulation mechanism in accordance with one exemplary embodiment ofthe present invention. This graph manipulation mechanism is similar tothat described above with regard to FIG. 11 except that a node may beexpanded by selecting unique values of fields in tables associated withan actual node.

Each node is bound to a set of attributes. During parametric search,each attribute may have more than one value. Nodes are not consideredunique based on the value of the attribute, but by their key, until theuser binds a value to the key. This binding prunes the graph at thecorresponding node to eliminate sub-graphs that could not be derivedwithout this binding. For example, node A may have a child node B withattributes named ‘health’ and ‘host’. The corresponding values for theattribute ‘health’ may be ‘good’ and ‘bad’. The corresponding values forthe attribute ‘host’ may be ‘host1.domain.com’ and ‘host2.domain.com’.The actual transaction may have a binding of the health to the host,such that host1.domain.com has bad health and the host2.domain.com hasgood health. The user does not see this binding until he/she narrows theparametric search by binding either the health attribute or the hostattribute. By binding a value on an attribute, e.g. health to the valuebad, then attribute host is implicitly bound to hostl.domain.com.

Consider a modification of the example where there was a third host,host3.domain.com, for which the actual transaction data bound the healthto bad. By binding the health to bad in the parametric search, thehost1.domain.com would be eliminated from the attribute values to whichhost could be bound.

FIG. 13 is an exemplary diagram of a child node ordering graphmanipulation mechanism in accordance with one exemplary embodiment ofthe present invention. With this graph manipulation mechanism, the orderin which child nodes are presented in the graphical representation maybe selected based on attributes of the child nodes. These attributes maybe the name of the child node, host name, transaction, application,user, response time, and the like. Any ordering criteria may be usedwithout departing from the spirit and scope of the present invention.For example, in order to more quickly identify possible root causes oferrors or problems, the child nodes may be ordered such that the worstperforming child nodes are at the top of the group of child nodes.

With this graph manipulation mechanism, the ordering criteria may be seta priori or may be input by a user at the time the graphicalrepresentation is to be generated. This ordering criteria is then usedalong with an ordering algorithm to traverse the first graph datastructure and copy entries from the first graph data structure to asecond graph data structure in a proper order according to the orderingcriteria. The resulting second graph data structure is then used torender the graphical representation of the modified transactionprocessing topology.

FIG. 13 illustrates two orderings of child nodes that may be obtainedusing the ordering mechanism of the present invention. As shown in FIG.13, when the first graph 1310 is generated according to transactionprocessing monitor data obtained from monitoring transaction processingby the ITMTP system, the child nodes may be in a random order based onhow the child nodes are encountered during transaction monitoring. Withone embodiment of the present invention, i.e. graph 1320, the childnodes may be ordered in ascending order. In another embodiment of thepresent invention, i.e. graph 1330, the child nodes may be ordered indescending order.

This mechanism permits any ordering of the child nodes that is deemed tobe most helpful in identifying the root cause of errors or problems withtransaction processing. Using the ordering mechanism, child nodes thathave attributes indicative of being sources of problems with regard totransaction processing may be placed at the top of a group of childnodes so that they are more easily noticed by a user. For example, thechild nodes may be ordered according to worst response times such thatthe most probable root cause of an error or problem is placed at the topof the group of child nodes.

In addition, the number of child nodes that are actually displayed maybe limited to a designated number. Thus, once ordering of the childnodes is performed in accordance with the embodiments described above,only the designated number of child nodes from the top of the reorderedgroup will actually be displayed. For example, if the limit is set to10, only the top 10 child nodes in the reordered group of child nodeswill be displayed. Child nodes appearing in the group after the 10 childnode will not be present in the modified graphical representation of thetransaction processing topology.

While various mechanisms for graph manipulation have been describedabove, these are not exhaustive of the possible graph manipulationmechanisms that may be implemented using the present invention. To thecontrary, the present invention is intended to include any graphmanipulation mechanism that may be applied to actual graphs oftransaction processing performance monitoring data in order to identifyand emphasize root causes of errors or problems in transactionprocessing of an enterprise system. For example, another graphmanipulation may be one in which nodes representing root causes oferrors may be directly linked to the root of the graph with all otherchild nodes removed. Other graph manipulation mechanisms, which maybecome apparent to those of ordinary skill in the art in view of thepresent disclosure, are intended to be within the spirit and scope ofthe present invention.

It should also be noted that while the above graph manipulationmechanisms are described separately for clarity, these graphmanipulation mechanisms may be used in conjunction with one another.Thus, both the HTAU graph manipulation mechanism and the child orderinggraph manipulation may be used together, for example. In suchembodiments, a first graph manipulation mechanism may be applied to theactual graph data structure in order to generate a first virtual graphdata structure. A second graph manipulation mechanism may then beapplied to the first virtual graph data structure in order to generate asecond virtual graph data structure. This process may be repeated foreach subsequent graph manipulation mechanism.

Also, as noted above, these graph manipulation mechanisms may beperformed automatically, manually, or both. With an automated mechanism,based on the identified problem location(s) in a transaction processingtopology, as determined by the ITMTP system, an appropriate graphmanipulation mechanism may be selected that would best emphasize theproblem location(s). Thus, for example, if the problem location is in achild node that is one of one hundred child nodes of a parent node, thenthe child ordering mechanism may be used along with a limit on how manychild nodes are displayed. As a result, the child node in which theproblem is detected may be more easily identified.

FIG. 14 is a flowchart that illustrate outlines an overall graphmanipulation mechanism in accordance with the present invention. It willbe understood that each block of the flowchart illustration, andcombinations of blocks in the flowchart illustration, can be implementedby computer program instructions. These computer program instructionsmay be provided to a processor or other programmable data processingapparatus to produce a machine, such that the instructions which executeon the processor or other programmable data processing apparatus createmeans for implementing the functions specified in the flowchart block orblocks. These computer program instructions may also be stored in acomputer-readable memory or storage medium that can direct a processoror other programmable data processing apparatus to function in aparticular manner, such that the instructions stored in thecomputer-readable memory or storage medium produce an article ofmanufacture including instruction means which implement the functionsspecified in the flowchart block or blocks.

Accordingly, blocks of the flowchart illustration support combinationsof means for performing the specified functions, combinations of stepsfor performing the specified functions and program instruction means forperforming the specified functions. It will also be understood that eachblock of the flowchart illustration, and combinations of blocks in theflowchart illustration, can be implemented by special purposehardware-based computer systems which perform the specified functions orsteps, or by combinations of special purpose hardware and computerinstructions.

As stated above, FIG. 14 is a flowchart outlining an exemplary operationof the present invention when performing graph manipulations to identifyand emphasize root causes of transactional processing problems inaccordance with one exemplary embodiment of the present invention. Asshown in FIG. 14, the operation starts by collecting and storingtransaction processing performance data in a database (step 1410). Thetransaction processing performance data is then utilized to generate afirst graph data structure of a transaction processing topology (step1420). One or more graph manipulation mechanisms are selected to beapplied to the first graph data structure (step 1430). This may be doneeither automatically, manually, or both.

A first graph manipulation mechanism is applied to the first graph datastructure in order to generate a second graph data structure (step1440). A determination is then made as to whether there are additionalgraph manipulation mechanisms to be applied (step 1450). If so, a nextgraph manipulation mechanism is applied to the second graph datastructure to generate a modified second graph data structure (step1460). The modified second graph data structure is then set as thesecond graph data structure (step 1470) and the operation returns tostep 1450.

If there are no additional graph manipulation mechanisms to be applied,the second graph data structure is used to generate a graphicalrepresentation of the transaction processing topology (step 1480). Thisgraphical representation is modified from the graphical representationthat would be obtained from the first graph data structure due to theapplication of the one or more graph manipulation mechanisms.

Thus, the present invention provides a plurality of graph manipulationmechanisms through which a first graph of a transaction processingtopology, obtained from transaction processing performance monitoringdata, may be modified. These modifications are used to provide a graphof the transaction processing topology through which a user may moreeasily identify the root cause of transaction processing problems in anenterprise system.

It is important to note that while the present invention has beendescribed in the context of a fully functioning data processing system,those of ordinary skill in the art will appreciate that the processes ofthe present invention are capable of being distributed in the form of acomputer readable medium of instructions and a variety of forms and thatthe present invention applies equally regardless of the particular typeof signal bearing media actually used to carry out the distribution.Examples of computer readable media include recordable-type media, suchas a floppy disk, a hard disk drive, a RAM, CD-ROMs, DVD-ROMs, andtransmission-type media, such as digital and analog communicationslinks, wired or wireless communications links using transmission forms,such as, for example, radio frequency and light wave transmissions. Thecomputer readable media may take the form of coded formats that aredecoded for actual use in a particular data processing system.

The description of the present invention has been presented for purposesof illustration and description, and is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the art. Theembodiment was chosen and described in order to best explain theprinciples of the invention, the practical application, and to enableothers of ordinary skill in the art to understand the invention forvarious embodiments with various modifications as are suited to theparticular use contemplated.

1. A method, in a data processing system, for identifying problemcomponents of an enterprise computing system, comprising: obtainingtransaction processing performance data for the enterprise computingsystem; generating a first graph data structure of a transactionprocessing topology of the enterprise computing system based on thetransaction processing performance data; applying one or more graphmanipulation mechanisms to the first graph data structure to generate asecond graph data structure of the transaction processing topology; andgenerating a graphical representation of the transaction processingtopology based on the second graph data structure, wherein the secondgraph data structure is a modified form of the first graph datastructure.
 2. The method of claim 1, wherein applying one or more graphmanipulation mechanisms to the first graph data structure includesreceiving input from a user designating a particular type of graphmanipulation mechanism to perform on the first graph data structure. 3.The method of claim 1, wherein applying one or more graph manipulationmechanisms to the first graph data structure includes automaticallyidentifying a graph manipulation mechanism to be applied to the firstgraph data structure based on characteristics of the first graph datastructure.
 4. The method of claim 3, wherein the characteristics of thefirst graph data structure include identified problem locations in thefirst graph data structure.
 5. The method of claim 1, wherein the one ormore graph manipulation mechanisms modify the first graph data structuresuch that root causes of problems in the enterprise computing system areemphasized and brought to a forefront of a graphical representation ofthe transaction processing topology of the enterprise computing system.6. The method of claim 1, wherein the one or more graph manipulationmechanisms include applying a monitoring policy to the first graph datastructure, wherein the monitoring policy identifies types of componentsof the enterprise computing system that are to be removed from the firstgraph data structure, and wherein applying the monitoring policy to thefirst graph data structure includes generating a second graph datastructure in which nodes corresponding to the identified types ofcomponents in the monitoring policy are not present.
 7. The method ofclaim 1, wherein the one or more graph manipulation mechanisms include atree reversal mechanism in which child nodes of the first graph datastructure are represented as parent nodes in the second graph datastructure and parent nodes in the first graph data structure arerepresented as child nodes in the second graph data structure.
 8. Themethod of claim 1, wherein the one or more graph manipulation mechanismsinclude a child node hiding mechanism in which child nodes in the firstgraph data structure are not present in the second graph data structure.9. The method of claim 1, wherein the one or more graph manipulationmechanisms include a unique parent/common child node view switchingmechanism in which a view of two or more branches of the first graphdata structure which point to a common child node may be depicted in thesecond graph data structure as separate branches or branches pointing toa common child node depending on the state of the switching mechanism.10. The method of claim 1, wherein the one or more graph manipulationmechanisms include a parametric value child node limitation mechanism inwhich child nodes in the first graph data structure that do not includea particular value of a selected parameter are eliminated in the secondgraph data structure.
 11. The method of claim 1, wherein the one or moregraph manipulation mechanisms include a parametric search mechanism inwhich nodes of the first graph data structure having particularparameters are removed from the second graph data structure.
 12. Themethod of claim 1, wherein the one or more graph manipulation mechanismsinclude a child node ordering mechanism in which an order of child nodesin the first graph data structure is modified in a second graph datastructure according to ordering criteria.
 13. A computer program productin a computer readable medium for identifying problem components of anenterprise computing system, comprising: first instructions forobtaining transaction processing performance data for the enterprisecomputing system; second instructions for generating a first graph datastructure of a transaction processing topology of the enterprisecomputing system based on the transaction processing performance data;third instructions for applying one or more graph manipulationmechanisms to the first graph data structure to generate a second graphdata structure of the transaction processing topology; and fourthinstructions for generating a graphical representation of thetransaction processing topology based on the second graph datastructure, wherein the second graph data structure is a modified form ofthe first graph data structure.
 14. The computer program product ofclaim 13, wherein the third instructions for applying one or more graphmanipulation mechanisms to the first graph data structure includeinstructions for receiving input from a user designating a particulartype of graph manipulation mechanism to perform on the first graph datastructure.
 15. The computer program product of claim 13, wherein thethird instructions for applying one or more graph manipulationmechanisms to the first graph data structure include instructions forautomatically identifying a graph manipulation mechanism to be appliedto the first graph data structure based on characteristics of the firstgraph data structure.
 16. The computer program product of claim 15,wherein the characteristics of the first graph data structure includeidentified problem locations in the first graph data structure.
 17. Thecomputer program product of claim 13, wherein the one or more graphmanipulation mechanisms modify the first graph data structure such thatroot causes of problems in the enterprise computing system areemphasized and brought to a forefront of a graphical representation ofthe transaction processing topology of the enterprise computing system.18. The computer program product of claim 13, wherein the one or moregraph manipulation mechanisms include instructions for applying amonitoring policy to the first graph data structure, wherein themonitoring policy identifies types of components of the enterprisecomputing system that are to be removed from the first graph datastructure, and wherein applying the monitoring policy to the first graphdata structure includes generating a second graph data structure inwhich nodes corresponding to the identified types of components in themonitoring policy are not present.
 19. The computer program product ofclaim 13, wherein the one or more graph manipulation mechanisms includeinstructions for a tree reversal mechanism in which child nodes of thefirst graph data structure are represented as parent nodes in the secondgraph data structure and parent nodes in the first graph data structureare represented as child nodes in the second graph data structure. 20.The computer program product of claim 13, wherein the one or more graphmanipulation mechanisms include instructions for a child node hidingmechanism in which child nodes in the first graph data structure are notpresent in the second graph data structure.
 21. The computer programproduct of claim 13, wherein the one or more graph manipulationmechanisms include instructions for a unique parent/common child nodeview switching mechanism in which a view of two or more branches of thefirst graph data structure which point to a common child node may bedepicted in the second graph data structure as separate branches orbranches pointing to a common child node depending on the state of theswitching mechanism.
 22. The computer program product of claim 13,wherein the one or more graph manipulation mechanisms includeinstructions for a parametric value child node limitation mechanism inwhich child nodes in the first graph data structure that do not includea particular value of a selected parameter are eliminated in the secondgraph data structure.
 23. The computer program product of claim 13,wherein the one or more graph manipulation mechanisms includeinstructions for a parametric search mechanism in which nodes of thefirst graph data structure having particular parameters are removed fromthe second graph data structure.
 24. The computer program product ofclaim 13, wherein the one or more graph manipulation mechanisms includeinstructions for a child node ordering mechanism in which an order ofchild nodes in the first graph data structure is modified in a secondgraph data structure according to ordering criteria.
 25. An apparatusfor identifying problem components of an enterprise computing system,comprising: means for obtaining transaction processing performance datafor the enterprise computing system; means for generating a first graphdata structure of a transaction processing topology of the enterprisecomputing system based on the transaction processing performance data;means for applying one or more graph manipulation mechanisms to thefirst graph data structure to generate a second graph data structure ofthe transaction processing topology; and means for generating agraphical representation of the transaction processing topology based onthe second graph data structure, wherein the second graph data structureis a modified form of the first graph data structure.